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DETAILED ACTION 

1. Claims 1-16, 19-23, 25-28 have been examined and are pending. 
Claims 1, 6, 23, 25, and 27 have been amended. 

Response to Arguments 

2. Applicant's arguments filed 5/23/2005 have been fully considered but they are not 
persuasive. 

As per Applicant's arguments relating to Maughan (ISAKMP), the Applicant 
argues that what ISAKMP defines is actually " a proposal as a list in decreasing order of 
preference of the protection suites that a system considers acceptable to protect traffic 
under a given situation". Applicant further argues that nothing in the ISKMP reference, 
alone or in combination with the other art of record teaches or suggests ordering security 
configuration proposal having a higher level of security is offered before a security 
configuration proposal having a lesser level of security' 1 as claimed and that the teachings 
of ISKMP are ambiguous on this topic at best" 

The Examiner responds that ordering the protection suites "in decreasing order of 
preference that a system considers acceptable to protect traffic under a given situation" , 
suggests ordering from a higher level of security to a lesser level of security depending 
on a given specific situation. ISAKMP definition of proposals "in decreasing order of 
preference acceptable by the system" inherently means protection suites with higher 
security is first offered before a lesser security. That is, a lesser security level is less 
preferred that a higher level of security. 
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Furthermore, The Examiner thoroughly reviewed the cited section of the 
specification {paragraph 0036) where the Applicant makes reference to define the terms 
"higher level of security" and "lesser level of security". The Examiner was unable to 
locate clear definition of the terms as claimed. Hence, the terms in the claims, at best, are 
given their broadest reasonable interpretation. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of the 
various claims was commonly owned at the time any inventions covered therein were 
made absent any evidence to the contrary. Applicant is advised of the obligation under 
37 CFR 1.56 to point out the inventor and invention dates of each claim that was not 
commonly owned at the time a later invention was made in order for the examiner to 
consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 

Claims 1 3-7, 9-16, 19-23, 25-26 and 27 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over prior art of record, D. Harkins, D. Carrel, "The Internet Key 
Exchange (IKE)", Request for Comments (2409) and further in view of Maughan et al. 
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(IDS filed 1/30/2003), " Internet Security Association and Key Management Protocol 
(ISAKMP)", Request for Comments (2408). 

3. As per claims 1, 6, 23, 25 and 27, IKE (RFC 2409) discloses configuring a 
tunnel comprising [RFC 2409 discloses processes for implementing negotiating virtual 
private network (VPN) providing a remote user from a remote site access to a secure host 
or network see page 2, 2 nd paragraph in Discussion]: 

initiating, by a first peer, a negotiation with a second peer, the 
negotiation including a plurality of security configuration proposals [Page 3, 
section 3.2, SA or security association with one or more proposals which 
corresponds to plurality of security configuration proposals provided by an 
initiator for negotiation, see page 9, paragraph 6 wherein during security 
association negotiation, initiators present offers for potential security associations 
to responders, see also page 23, section 7.1 phase 1 using main mode]; 

sending, by the second peer, information to the first [page 24, in phase 1 
using main mode, the responders selects (i.e. extracts), and returns one transform 
proposal]; 

extracting, by the first peer, a security configuration selected from among 
the plurality of security configuration proposals from the information sent by the 
second peer; and 

establishing, using the security configuration, a tunnel between the first 
peer and the second peer [page 5, in Phase 2 where security associations are 
negotiated on behalf of service such as IPsec or any other service which needs key 
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material and/or parameters negotiation. RFC 2409 describes that "Quick Mode" 
accomplishes a phase 2 exchange. 

RFC 2409 does not expressly disclose wherein the first peer orders the plurality of 
security configuration proposals such that a more secure security configuration proposal 
is offered before a less secure security configuration proposal. 

However, Maughan et al. (RFC 2408) discloses that the first peer orders the 
plurality of security configuration proposals such that a security configuration proposal 
having a higher level of security is offered before a security configuration proposal 
having a lesser level of security [page 19, paragraph 6, i.e. initiator (i.e. first peer) sends a 
proposal containing more than one proposal which are sent in decreasing preference 
which corresponds to ordering proposals such that a more secure security configuration 
proposal (i.e. more preferred one) is offered before less secure security proposal (i.e. less 
preferred one)]. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to adapt the IKE protocol (RFC 2409) with the teachings IS AKMP ( 
RFC 2408) to have the first peer (i.e. initiator) to order the plurality of security 
configuration proposals such that more secure security configuration proposal is offered 
before less secure security configuration proposal to allow the second peer (responder) to 
make its policy take precedence over the first peer (initiator) by selecting the proposal 
best suited for responder' s local security policy. 

As per claims 3, 7 and 26, IKE (RFC 2409) discloses wherein the establishing a 
tunnel includes conducting a phase2 negotiation in the IPSec protocol [page 5, in Phase 2 
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where security associations are negotiated on behalf of service such as IPsec or any other 
service which needs key material and/or parameters negotiation]. 

As per claims 4 and 5, IKE (RFC 2409) discloses initiating, by the first peer, a 
preliminary negotiation with the second peer, 

wherein the initiating a preliminary negotiation includes conducting a phase 1 
negotiation in the IPSec protocol [Phase 1 (or preliminary negotiation) where two 
ISAKMP peers establish a secure, authenticated channel with which to communicate (i.e. 
a security association, SA). RFC 2409 discloses that " Main mode" and " Aggressive 
Mode" each accomplish a phase one exchange]. 

As per claim 9, IKE (RFC 2409) discloses wherein the initiating comprises 
requesting, by the first peer, that the second peer send information, the information 
including policy information to define a subsequent negotiation between the first peer and 
the second peer [page 8, paragraph 6, i.e. Main mode is an instantiation of the ISAKMP 
Identity Protect Exchange]. 

As per claim 10, IKE (RFC 2409) discloses wherein the policy information 
defines one or more security associations [page 5, section 3.4, a Security association is a 
set of policy and keys used to protect information]. 

As per claims 11 and 15, IKE (RFC 2409) discloses wherein the information 
sent by the second peer comprises sets of attributes, the attributes including security 
parameters and network addresses [page 17, 4th and 6th paragraph, i.e. the identities of 
the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the 
ISAKMP peers (recited in claim 15), without any implied constraints on the protocol or 
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port numbers allowed, unless client identifiers are specified in Quick Mode and all offers 
made during a Quick Mode are logically related and must be consistent. For example, if a 
KE payload is sent, the attribute describing the Diffie-Hellman group (see section 6.1 and 
[Pip97]) MUST be included in every transform of every proposal of every SA being 
negotiated. Similarly, if client identities are used, they MUST apply to every SA in the 
negotiation]. 

As per claims 12, 13 and 14, IKE (RFC 2409) discloses wherein the establishing 
a tunnel comprises negotiating, by the first peer with the second peer, to generate a secure 
key, 

wherein the negotiating to generate a secure key includes conducting a phase2 
negotiation in the IPSec protocol [page 8, section 5 discloses that there are two basic 
methods used to establish an authenticated key exchange: Main Mode and Aggressive 
Mode. Each generates authenticated keying material from an ephemeral Diffie-Hellman 
exchange. Main Mode MUST be implemented; Aggressive Mode SHOULD be 
implemented. In addition, Quick Mode (recited in claim 14) MUST be implemented as a 
mechanism to generate fresh keying material and negotiate non-ISAKMP security 
services]. 

As per claim 16, IKE (RFC 2409) discloses wherein a shared secret is stored 

on the 

first peer before the negotiation [page 16, 5.4 Phase 1 Authenticated With a Pre-Shared 
Key]. 

As per claims 19-22, IKE (RFC 2409) discloses wherein the negotiation utilizes 
the base mode exchange extension of the IPSec protocol, 
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wherein the initiating a negotiation further comprises sending, by the first peer to 
the second peer, the identity of the first peer, 

wherein the initiating a negotiation includes conducting a phase 1 negotiation in 
the IPSec protocol, 

wherein the negotiation utilizes one of main mode and aggressive mode of the 
IPSec protocol [see page 16, section 5.4, Phase 1 Authenticated With a Pre-Shared Key 
for limitations recited in claims 19, 20, 21 and 22 disclosing a key derived by some out- 
of-band mechanism may also be used to authenticate the exchange. The actual 
establishment of this key is out of the scope of this document. 

When doing a pre-shared key authentication, Main Mode is defined as 

follows: 

Initiator Responder 



HDR, SA --> 

<-- HDR, SA 
HDR, KE, Ni --> 

<-- HDR, KE, Nr 
HDR*, IDii, HASH J --> 

<-- HDR*, IDir, HASHJR 
Aggressive mode with a pre-shared key is described as follows: 
Initiator Responder 
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HDR, SA, KE, Ni, EDii --> 

<-- HDR, S A, KE, Nr, IDir, HASH_R 
HDR, HASHJ 

When using pre-shared key authentication with Main Mode the key can only be 
identified by the IP address of the peers since HASH_I must be computed before the 
initiator has processed IDir. Aggressive Mode allows for a wider range of identifiers of 
the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to 
maintain multiple, different pre-shared keys and identify the correct one for a particular 
exchange]. 

4. Claims 2, 8, 26 and 28 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over prior art of record, D. Harkins, D. Carrel as applied in claims 1, 6, 23, 25 and 27 
above and D. Dukes, R. Pereira, "ISAKMP Configuration Method", The Internet-Draft, 
March 2000 and further in view of Y. Dayan, S. Bitan, "IKE Base Mode", Internet-Draft, 
January 2000. 

As per claims 2, 8, 26 and 28, ISAKMP Configuration method (IDS#5) discloses 
a new ISAKMP configuration method to allow IPsec-enabled entities to acquire and 
share configuration information (i.e. negotiation comprises a request/reply negotiation), 
D. Dukes, R. Pereira, page 11, section 7. That is, retrieving certain information from the 
other peer before the non-ISAKMP SA can be established is sometimes useful, Y. Dayan, 

5. Bitan, page 3, section 1]. 
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Action is Final 

5. Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 
706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 
1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the 
advisory action. In no event, however, will the statutory period for reply expire later than 
SIX MONTHS from the mailing date of this final action. 

Conclusion 

6. Prior arts made of record, not relied upon: 

US 6, 754,831 B2 to Brownell is directed to a method and apparatus for managing 
network access to internal hosts protected by a firewall. A user on an external host logs in 
into a firewall. Once the user has been authenticated to the firewall, a session is 
established for the user, and tunnel configuration is transmitted to the user's process on 
the external host. The tunnel configuration data indicates the configuration of at least one 
tunnel for connecting to at least one internal host protected by the firewall. When creating 
a socket for connecting to the internal host, the socket is configured based on the tunnel 
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configuration data. Tunnel objects and tunnel socket objects may be specially configured 
to establish a connection in a way that takes advantage of the power and simplicity of the 
inheritance feature of object oriented software. Various tunnel classes are provided to 
configure tunnels in a variety of manners. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Taghi T. Arani whose telephone number is (571) 272- 
3787. The examiner can normally be reached on 8:00-5:30 Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Ayaz Sheikh can be reached on (571) 272-3795. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). 




Taghi T. Arani, Ph.D. 



Examiner 
Art Unit 2131 




